I'm holding this off until 1.10 so it can be incorporated into #1059

Did some testing and it looks like this is all working on my end. To recap: SuperDirt handshakes/bus mappings are handled by individual targets, rather than by the stream. This means that each handshake occurs on a separate UDP port, and SuperDirt targets no longer use the Tidal control listener port for sending messages.

Fixes #1030 as well—a bug where the control bus mappings weren't actually being properly used to address bus messages (and therefore bus params wouldn't work if SuperDirt allocated a different block control buses than 0-n)

In general, this is part of a broader effort to separate out different pieces of stream functionality (ie, consolidate the listener logic, consolidate SuperDirt-specific features, etc). I know @polymorphicengine has been thinking along these lines, so let me know if you have any thoughts!

i think this is looking good!
are you also planning to move into the direction of the extendable OSC controller? (#982)

i mean it is actually pretty much there, we only need to abstract over the act function inside ctrlResponder so people can extend it like

act' :: O.Message -> Stream -> IO ()
act' matchingMessage str = customAction str
act' m str = defaultAct m str

are you also planning to move into the direction of the extendable OSC controller?

Yes, though I think in a separate PR. My (maybe controversial) thought is that the Stream object shouldn't own the controller/listener at all, since the listener is just a wrapper around functions that the Stream object exposes. Or else we move to a point where all of the relevant code is split across a bunch of small logical components (a clock, a listener, some targets, a playmap abstraction) and Stream is just a set of MVars that holds together a default (but entirely optional) Tidal setup.

uh nice, @matthewkaney!

Ready for merge?

i did some testing on this just now, it looks good to me and solves my control bus woes 😍

Oh great! I wasn't sure if everything still worked after the messy merge, but that's good to hear.

I'll test a bit this evening to see if I catch anything amiss in how it behaves and look into why the builds are failing. After that, this should be good to merge tomorrow morning!

@yaxu Yes, I think that can be merged! I guess the latest build issue is some error with the Ormolu action, possibly related to the fact that this PR is from a fork rather than a branch on the main repository? Good to address at some point, but doesn't seem like it will be an issue here after merge

Excellent thanks! I think the build issue was a small formatting thing that was already automatically fixed.